The increasing size and complexity of the information technology (IT) needs of enterprises force periodic upgrade of their IT infrastructures—in this context, software applications ranging from operating systems, middleware and end-user applications need to be migrated. The process associated with migration may range from simple to complex, depending on the number of elements which change during the upgrade—the most complex being a change in both the hardware and the type of operating system. Such a change typically necessitates a complete rebuilding of the middleware and end-user application stack to support the same enterprise functions on the new platform.
In many migration scenarios the move to a new system is prompted by inadequacies or performance bottlenecks in the old system. Thus, a simple provisioning and configuration of the new machines to match the capabilities of the old system will often not be sufficient. Given that the typical server consolidation project may rely heavily on virtualized and networked resources, it is not clear that over-provisioning individual systems will eventually meet the needs (such as enterprise needs) that were the driving factors behind the migration. For example, in the case of a cluster of web servers, if the performance bottleneck is created by a shared database increasing the number of servers would not lead to a significant increase in the number of transactions that can be handled in a unit time. A careful analysis of the resource sharing between virtual servers on the same hardware and physical servers sharing networked storage of peripherals would be required to obtain the right provisioning scheme.
In the prior art, there are generally two common methods for migrating software applications from the old system environment to the new. As shown in FIG. 1, the first method of migrating software is a manual process, in which the system administrator or user 102 manually installs and configures software 104 on a new system environment 106, for example, by following instructions provided in the documentation for the software application(s) and new system environment, by inspection of the existing deployment and configuration data files on the old infrastructure 108, or other manual techniques. This method is very tedious and time consuming, prone to human error, and dependent upon the level of training and skill of the individual making the manual changes. By way of completeness, in this process, an “as-is system” has one or more software applications 110 that have been configured and deployed, as per blocks 112, 114, resulting in the old system environment 108. The configuration and deployment are captured, as indicated by the arrows In the “to-be” system, one or more software applications 104 are present, and are configured and deployed as per blocks 116, 118, to obtain the new system environment 106. The configuration and deployment 116, 118 are the result of the setting and installation by administrator or user 102, as indicated by the arrows
According to the second method of migrating software applications, as shown in FIG. 2, a separate executable apparatus called a Migration Utility 202 is provided to read the specific deployment and configuration files of the software application 110 that is the migration target, as well as the resource(s) required by the software applications within the old system environment 108. Elements in FIG. 2 similar to FIG. 1 have received the same reference numeral. Utility 202 maps the deployment and configurations of software applications to new system environment 106, to generate deployment plan(s) and configuration files, and then provisions and sets software applications on the new system environment 106 based on the deployment plan and configuration files. This method has the advantage that the process can be implemented automatically, leading to improved efficiency However, this kind of method can only achieve software application execution in the new system environment via simple mapping, provisioning, and configuring of software application(s) from the old to new system environments. In the prior art it is not clear how to translate a requirement (for example, an enterprise requirement) for improved performance of a software application into specific migration provisioning decisions.